The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Software applications operating in a network environment exchange application messages. An “application message,” or simply “message”, as used herein, refers to a message emitted or consumed by a software element that is logically located at Layer 5 or higher of the OSI reference model. Messages may be contained in more than one data frame, packet or segment. For simplicity, the term “packet” is used to refer to a unit of organization under an internetworking protocol, such as data frame, packet or segment, at Layer 2, 3 or 4 of the OSI reference model.
Application end points such as clients and servers in a distributed system communicating over a network often need to authenticate users' credentials presented in an application message and, if the authentication succeeds, authorize the users for specific privileges for using system or application resources. Authentication and authorization usually is done by application end points. Application end points, or simply applications, are required to perform authentication and authorization operations relating to messages received. Under this approach, logic extracting user credentials from application messages is part of application processes. However, to perform the extraction, applications need to know specific details of application message formats such as where user credentials are stored.
Additionally, authentication or authorization logic often communicates with one or more authentication or authorization service providers or data stores. Thus, applications often need to know specific details of service providers or data stores such as where and how the user credentials extracted from messages can be compared with trusted user credentials kept by the service providers or data stores. To complicate the matter, some service providers or data stores may not be based on industry standards in providing the authentication or authorization related services.
Applications' needs for authentication and authorization may change. For example, service provider may change. An application may need to support LDAP, instead of Kerberos for authentication. Or an application may need to access a data store, instead of a service provider.
Furthermore, formats of application messages may change with respect to user credentials. User credentials may be specified in an application protocol header (say HTTP header) or SOAP header. Also they can come as a part of application message body in an application specific format, or in a payload.
Generally, in past approaches, in order to handle any of these changes, the implementation of the application has to be changed. This is time-consuming and requires significant resources in programming labor.
Further, in typical past approaches, the number of points at which authentication and authorization are performed is proportional to the number of application endpoints. This is a waste of application processing resources.
Also, in typical past approaches, authentication and authorization by an application can only authenticate and authorize based on user credentials present in an application message. Since the application typically is ignorant of what user credentials may present below OSI layer 5, authentication and authorization for such user credentials typically has to be performed elsewhere. An example of such user credentials is an SSL certificate. This results in a fragmented processing, waste of resources and potential inconsistent outcome.